À propos du contrôle des exécutables (Executable Control)
Dans cette section :
Trusted Ownership
Lors du processus de mise en correspondance des règles, la vérification de propriétaire de confiance (Trusted Ownership) est exécutée sur les fichiers et dossiers, afin de garantir que le propriétaire des éléments fait partie de la liste des propriétaires de confiance spécifiée dans la configuration de règle par défaut.
Par exemple, si le fichier que vous voulez exécuter correspond à un élément autorisé, un contrôle de sécurité supplémentaire s'assure que le propriétaire du fichier correspond également à la liste Propriétaires de confiance. Si un fichier légitime a été altéré ou si un fichier qui constitue une menace de sécurité a été renommé pour ressembler à un fichier autorisé, la vérification Trusted Ownership identifie cette irrégularité et empêche l'exécution du fichier.
Par défaut, les dossiers/partages réseau sont refusés. Ainsi, si le fichier réside dans un dossier réseau, vous devez ajouter ce fichier ou son dossier à la règle en tant qu'élément autorisé. Sinon, même si le fichier réussit le test de vérification Trusted Ownership, la règle interdit l'accès.
La vérification Trusted Ownership est inutile pour les éléments comportant des signatures de fichier, car ils ne peuvent pas être imités.
Les propriétaires de confiance par défaut sont :
- SYSTEM
- BUILTIN\Administrators
- %ComputerName%\Administrator
- NT Service\TrustedInstaller
Cela signifie que, par défaut, Contrôle des applications fait confiance aux fichiers dont le groupe BUILTIN\Administrators et l'administrateur local sont propriétaires. Contrôle des applications ne regroupe pas les recherches de propriétaires de confiance ; les utilisateurs membres de BUILTIN\Administrators ne sont PAS considérés par défaut comme étant de confiance. Les autres utilisateurs, même membres du groupe Administrateurs, doivent être ajoutés explicitement pour devenir des propriétaires de confiance. Vous pouvez étendre la liste ci-dessus pour inclure d'autres utilisateurs ou groupes.
Technologie
Contrôle des applications utilise des pilotes de filtre sécurisés et des stratégies de sécurité Microsoft NTFS pour intercepter toutes les demandes d'exécution. Les demandes d'exécution passent par le hook Contrôle des applications et toutes les applications indésirables sont bloquées. Les droits des applications reposent sur le propriétaire de l'application concernée et les propriétaires de confiance par défaut sont des administrateurs. Avec cette méthode, la stratégie actuelle d'accès aux applications est appliquée sans nécessiter de scripts ni de fonctions de gestion de liste. On appelle cela Trusted Ownership. Outre les fichiers exécutables, Contrôle des applications gère les droits sur le contenu des applications, comme les scripts VBScript, les fichiers batch, les paquets MSI et les tables de configuration de registre.
Trusted Ownership est la méthode par défaut de contrôle de l'accès aux applications dans Contrôle des applications. Elle utilise le modèle DAC (Discretionary Access Control - Contrôle d’accès discrétionnaire). Elle examine l'attribut Propriétaire du fichier et le compare à une liste prédéfinie de propriétaires de confiance. Si le propriétaire du fichier figure dans la liste, l'exécution du fichier est autorisée. Sinon, elle est refusée.
L'une des fonctions importantes de cette méthode de sécurité est la capacité à ne pas tenir compte du contenu du fichier proprement dit. Ainsi, Contrôle des applications peut contrôler à la fois les applications connues et les applications inconnues. Par convention, les systèmes de sécurité comme les applications antivirus comparent les motifs des fichiers à ceux figurant dans une liste connue pour identifier les menaces potentielles. Ainsi, la protection offerte est directement liée à la précision de la liste utilisée pour la comparaison. De nombreux malwares ne sont jamais identifiés ou, aux mieux, ne sont identifiés qu'après une certaine période, au cours de laquelle les systèmes sont vulnérables. Par défaut, Contrôle des applications autorise TOUT le contenu d'exécutable installé en local à s'exécute À CONDITION que le propriétaire de l'exécutable concerné figure dans la liste Propriétaires de confiance dans la configuration. L'administrateur doit alors fournir la liste des applications qui ne doivent pas s'exécuter depuis le sous-système de disque local, ce qui concerne généralement les applications d'administration comme mmc.exe, eventvwr.exe, setup.exe, etc.
S'il adopte cette approche, l'administrateur n'a pas besoin de connaître tous les détails de chaque portion de code exécutable nécessaire pour que l'ensemble d'applications fonctionne. En effet, le modèle Trusted Ownership autorise/refuse l'accès de manière appropriée.
Même si Contrôle des applications peut arrêter tous les malwares reposant sur un script exécutable dès leur introduction sur le système, Contrôle des applications n'est pas conçu pour remplacer les outils existants de suppression des malwares. Vous devez plutôt l'utiliser comme technologie complémentaire en plus de ces outils. Par exemple, même si Contrôle des applications peut bloquer l'exécution d'un virus, il ne peut pas le supprimer du disque.
Règle Trusted Ownership
Trusted Ownership n'a pas besoin de tenir compte de l'utilisateur connecté. Peu importe si cet utilisateur connecté est un propriétaire de confiance, un administrateur ou autre. Trusted Ownership repose sur l'utilisateur (ou le groupe) propriétaire d'un fichier sur le disque. Il s'agit généralement de l'utilisateur qui a créé le fichier.
L'on constate souvent que le propriétaire du fichier est le groupe BUILTIN\Administrators de la console Contrôle des applications. Il est également possible de déterminer si le propriétaire du fichier est un compte d'administrateur spécifique. Résultat dans les situations suivantes :
- Le propriétaire du fichier est le groupe BUILTIN\Administrators et ce groupe est marqué Propriétaire de confiance. Trusted Ownership autorise le fichier à s'exécuter.
- Le propriétaire du fichier est un administrateur distinct et cet administrateur est un propriétaire de confiance. Trusted Ownership autorise le fichier à s'exécuter.
- Le propriétaire du fichier est un administrateur distinct et cet administrateur n'est pas un propriétaire de confiance, mais le groupe BUILTIN\Administrators est un propriétaire de confiance. Trusted Ownership empêche le fichier de s'exécuter.
Dans ce dernier cas, même si l'administrateur propriétaire du fichier appartient au groupe BUILTIN\Administrators, le propriétaire du fichier n'est pas marqué De confiance. Le groupe n'est pas développé pour vérifier si le propriétaire concerné est marqué De confiance. Dans ce cas, pour autoriser le fichier à s'exécuter, il faut remplacer le propriétaire du fichier par un propriétaire de confiance, comme un administrateur de domaine ou local.
Niveaux de sécurité
Les règles Contrôle des applications vous permettent de définir des niveaux de sécurité afin de spécifier comment gérer les demandes d'exécution d'applications non autorisées par les utilisateurs, les groupes ou les périphériques auxquels une règle correspond.
Auto-autorisation
Dans certains environnements, les utilisateurs doivent ajouter de nouveaux exécutables à un ordinateur. Par exemple, c'est le cas des développeurs qui testent ou mettent à jour des logiciels en interne en permanence, ou des superutilisateurs qui ont besoin d'accéder à des applications nouvelles ou inconnues. La fonction Auto-autorisation permet aux superutilisateurs nommés d'exécuter les applications qu'ils ont introduites sur le système. Ces superutilisateurs peuvent ajouter des applications à un poste client sécurisé, même hors du bureau, sans faire appel au support IT. Les équipes de développement, les superutilisateurs et les administrateurs disposent ainsi de la flexibilité nécessaire pour installer et tester des logiciels, tout en bénéficiant d'un niveau élevé de protection contre les malwares et exécutables masqués.
Tous les utilisateurs configurés avec l'option Auto-autorisation peuvent choisir d'autoriser l'exécution d'un exécutable non marqué De confiance, une seule fois, plusieurs fois au cours de la même session ou toujours. Un audit complet fournit des détails comme le nom de l'application, l'heure et la date de l'exécution, et le périphérique. De plus, il est possible de faire une copie de l'application et de la stocker de manière centralisée pour examen.
Éléments autorisés et refusés
Éléments autorisés
L'approche par liste d'autorisations exige que chaque élément du contenu exécutable soit prédéfini avant que l'utilisateur émette la demande concernant l'application dans le système d'exploitation. Les détails de tout le contenu identifié de cette manière sont stockés dans une liste d'autorisations qui doit être consultée à chaque demande d'exécution. Si le fichier exécutable figure dans la liste d'autorisations, l'exécution est autorisée. Sinon, elle est refusée.
Les technologies fonctionnant de cette manière sont peu nombreuses, mais elles génèrent souvent des problèmes concernant le niveau d'administration nécessaire après l'implémentation. Cela vient de la nécessité d'ajouter à la liste d'autorisations tous les correctifs, niveaux de produit et mises à niveau, et de tenir ces données à jour.
Contrôle des applications prend entièrement en charge ce modèle de contrôle et y ajoute des étapes importantes pour renforcer la sécurité de ce modèle. Ces ajouts permettent notamment d'inclure des signatures numériques SHA-1, SHA-256 et Adler-32, si bien qu'il faut non seulement que le nom de l'application et le chemin de fichier coïncident, mais également que la signature numérique de l'exécutable concerné figure dans la base de données. De plus, Contrôle des applications ajouter à la liste le chemin complet de l'exécutable pour garantir que les trois éléments suivants correspondent, avant l'exécution de l'application :
Nom de fichier - Par exemple, winword.exe.
Chemin de fichier - Par exemple, C:\Program Files\Microsoft Office\Office\digital signature
Pour atteindre un niveau supérieur de contrôle avec cette technologie, Contrôle des applications ne se contente pas d'exploiter les détails des exécutables : il demande à l'administrateur de spécifier des DLL particulières en plus du reste du contenu exécutable, comme les contrôles ActiveX, les scripts Visual Basic et les scripts de commande.
Dans Contrôle des applications, les listes d'autorisations sont appelées Éléments autorisés. Les entrées de la liste Éléments autorisés incluent :
- Fichiers
- Dossiers
- Lecteurs
- Hachages de fichier
- Collections de règles
Éléments refusés
Par opposition aux listes d'autorisations, les listes de refus représentent potentiellement une mesure de sécurité de bas niveau. Le système génère et tient à jour une liste contenant les applications dont l'exécution doit être refusée. C'est la principale faiblesse de cette méthode : elle présume que toutes les applications dangereuses sont connues. Cela s'avère très peu utile pour la plupart des entreprises, en raison de l'accès par e-mail ou Internet, et/ou des cas où l'utilisateur peut introduire des fichiers et des applications sans intervention de l'administrateur.
Contrôle des applications n'a pas besoin de maintenir activement la liste des applications refusées, car toutes les applications qui n'ont pas été installées par l'administrateur (et, donc, dont il n'est pas propriétaire) sont bloquées grâce à Trusted Ownership.
L'une des principales raisons justifiant de bloquer des applications via une liste de refus est de permettre l'utilisation de Trusted Ownership pour la gestion des licences, en interdisant même l'exécution des applications connues (et donc, de confiance et avec propriétaire), jusqu'à ce qu'un administrateur autorise ultérieurement l'accès à l'application en question en définissant une règle d'utilisateur/groupe ou de client spécifique. Cette protection ne nécessite aucune configuration, sauf pour autoriser une application externe. En outre, la liste de refus est utile pour refuser l'accès aux fichiers appartenant à des propriétaires de confiance mais susceptibles de présenter un risque pour la sécurité. Par exemple, regedit.exe, ftp.exe, etc.